home *** CD-ROM | disk | FTP | other *** search
- Path: soap.news.pipex.net!pipex!usenet
- From: m.hendry@dial.pipex.com (Mathew Hendry)
- Newsgroups: comp.sys.amiga.programmer
- Subject: Re: 680X0 -> PPC translator?
- Date: Fri, 8 Mar 96 18:20:39
- Organization: Private node.
- Distribution: world
- Message-ID: <19960308.41E5A8.1098C@an157.du.pipex.com>
- References: <19960307.41C900.103A8@an168.du.pipex.com> <Dny169.BJH@cix.compulink.co.uk>
- NNTP-Posting-Host: an157.du.pipex.com
- X-Newsreader: TIN [AMIGA 1.3 950726BETA PL0]
-
- Jolyon Ralph (jralph@cix.compulink.co.uk) wrote:
- : > can come later - surely the aim should be to get as many applications
- : > working (if slowly, initially) as soon as possible.
- :
- : Of course. But if a PPC running predominantly 680x0 software through
- : emulation doesn't outperform the 680x0 code running on a real 040/060
- : chip, what's the point in going to PPC anyway?
-
- What makes you think that a good emulation would be any slower than a good
- static translation? The aim should be to 1) cache already translated code
- in memory 2) periodically update the file on disk with this translated code.
-
- In other words, the _user_ would effectively be guiding the static translation
- of an executable. With each run of the program, hopefully more code would be
- translated, and the program would run progressively faster. This completely
- removes the problem of misplaced code / data, because only code which would
- really be executed ends up being translated (you do have the problem of how
- to deal with programs which go haywire and jump into data segments, though -
- almost impossible to handle whichever method you use)...
-
- Note: DEC's FX!64 system uses this method, and claims 70% of native
- performance for fully translated programs.
-
- -- Mat.
-